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Abstract 

This  paper  uses  a  theory  of  composition  based  on  existential  and  uni¬ 
versal  properties.  Universal  properties  are  useful  to  describe  components 
interactions  through  shared  variables.  However,  some  universal  proper¬ 
ties  do  not  appear  directly  in  components  specifications  and  they  must 
be  constructed  to  prove  the  composed  system.  Coming  up  with  such  uni¬ 
versal  properties  often  requires  creativity.  The  paper  shows  through  two 
examples  how  this  construction  can  be  achieved.  The  principle  used  is 
first  presented  with  a  toy  example  and  then  applied  to  a  more  substantial 
problem. 


1  Introduction 

A  goal  of  compositional  systems  development  is  to  support  the  publication  of 
software  modules  in  a  repository  such  as  the  Web,  where  each  module  is  pub¬ 
lished  with  its  specification,  and  where  new  modules  can  be  created  by  compos¬ 
ing  existing  modules.  Hardware  vendors  publish  parts  lists  with  specifications, 
and  other  vendors  compose  these  parts  to  create  new  parts.  Personal  comput¬ 
ers  are  manufactured  in  this  fashion.  We  establish  properties  of  a  composed 
system  from  the  specifications  of  the  components;  we  do  not  consider  how  the 
components  are  implemented  provided  they  satisfy  their  specifications. 

Systems  can  be  developed  in  a  compositional  way  whether  the  development 
is  bottom-up  or  top-down  or  some  combination  of  the  two.  In  all  cases,  a  goal  is 
to  specify  each  component  so  that  the  component  can  be  used  in  a  wide  variety 
of  environments. 

"This  work  is  supported  by  a  grant  from  the  Air  Force  Office  of  Scientific  Research. 
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We  would  like  a  specification  of  a  software  module  to  name  only  variables 
used  in  that  module.  We  prefer  not  to  specify  one  module  using  variables  named 
in  other  modules  with  which  this  module  may  be  composed.  The  reason  for  this 
preference  is  to  allow  the  widest  latitude  for  the  environments  of  a  module. 
Specifying  variables  in  the  environment  can  over-specify  the  environment. 

A  property  is  a  predicate  on  systems.  A  specification  is  a  desired  property  of 
a  system.  (Usually,  a  specification  is  a  desired  property  which  is  a  conjunction 
of  desired  properties.)  A  local  property  of  a  system  is  a  property  that  names 
only  variables  of  that  system.  We  would  like  the  specification  of  a  system  to  be 
a  local  property  of  that  system. 

When  we  compose  components  to  get  larger  systems  we  may  find  that,  luck¬ 
ily  for  us,  all  the  properties  we  desire  for  the  composed  system  can  be  obtained 
in  a  straightforward  way  from  the  specifications  of  the  components.  In  other 
cases,  we  may  have  to  be  creative  in  proving  system  specifications  from  their 
component  specifications.  This  paper  is  an  exploration  of  how  we  can  prove 
system  properties  from  local  component  properties. 

This  paper  uses  a  theory  of  composition  proposed  in  [5,  6].  This  theory 
is  based  on  existential  and  universal  property  types.  A  property  type  is  an 
existential  type  when  it  holds  in  any  system  in  which  at  least  one  component 
has  the  property.  A  property  is  a  universal  type  when  it  holds  in  any  system  in 
which  all  components  have  the  property.  Consider  a  simple  example.  Imagine 
that  we  are  putting  pieces  together  in  a  jigsaw  puzzle.  An  example  of  a  universal 
property  is  ’’the  component  is  entirely  dark  colored.”  If  we  put  entirely  dark- 
colored  components  together  we  get  entirely  dark-colored  (larger)  components. 
An  example  of  an  existential  property  is:  ’’the  component  has  a  light-colored 
region.”  A  component  has  a  light-colored  region  if  it  has  a  subcomponent  with 
a  light-colored  region. 

Some  properties  are  neither  universal  nor  existential.  The  earlier  work,  how¬ 
ever,  proposes  a  theory  of  composition  based  on  universal  and  existential  prop¬ 
erties.  Conjunctions  of  these  properties  are  adequate  for  specifying  most  con¬ 
current  systems.  In  particular,  existential  properties  seem  to  play  an  important 
role  in  the  specification  of  distributed  systems  [3]. 

Here,  we  consider  the  case  of  a  shared  memory  system.  In  such  systems,  a 
compositional  approach  must  provide  means  to  describe  the  way  components 
modify  shared  variables. 

Components  specifications  do  not  describe  their  use  of  shared  variables  with 
existential  properties.  Specifications  about  one  component  must  make  assump¬ 
tions  on  the  way  other  components  modify  shared  variables.  One  way  is  to  use 
universal  properties  that  specify  how  all  components  use  shared  variables. 

However,  a  universal  property  of  one  component  referring  only  to  local  vari¬ 
ables  and  shared  variables  of  that  component  and  not  to  other  components’ 
local  variables  will  generally  not  be  satisfied  by  all  other  components,  which 
modify  shared  variables  according  to  their  local  variables.  This  is  because  each 
component  has  a  property  defined  in  terms  of  its  local  and  shared  variables,  and 
so  these  properties  are  different  for  different  components. 

To  cope  with  this  difficulty,  one  approach  is  to  build,  from  components 
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specifications,  a  universal  property  satisfied  by  all  components,  which  is  then  a 
system  property.  The  paper  presents  an  example  of  that  step. 

After  presenting  the  programming  model  used,  we  first  consider  a  toy  exam¬ 
ple  to  highlight  the  difficulties  related  to  universal  properties  and  the  way  they 
can  be  solved.  We  then  apply  the  same  principles  to  a  more  important  example: 
a  priority  mechanism  for  conflicting  processes. 


2  Programming  Model 

The  programming  model  that  we  use  to  illustrate  the  theory  is  the  model  used 
in  [6,  3]  which  is  derived  from  Unity  [4].  A  program  consists  of  a  set  of  typed 
variables,  an  initially  predicate  which  is  a  predicate  on  program  states,  a  finite 
set  C  of  commands,  and  a  subset  D  of  C  of  commands  subjected  to  a  weak 
fairness  constraint:  every  command  in  D  must  be  executed  infinitely  often.  The 
set  C  contains  at  least  the  command  skip  which  leaves  the  state  unchanged. 

The  program  composition  is  defined  to  be  the  union  of  the  sets  of  variables 
and  the  sets  C  and  D  of  the  components,  and  the  conjunction  of  the  initially 
predicates.  Such  a  composition  is  not  always  possible.  Especially,  composition 
must  respect  variable  locality  (a  variable  declared  local  in  a  component  should 
not  be  written  by  another  component)  and  must  provide  at  least  one  initial 
state  (the  conjunction  of  initial  predicates  must  be  logically  consistent).  We  use 
F  *  G  to  denote  that  programs  F  and  G  can  be  composed.  Then,  the  system 
resulting  from  that  composition  is  denoted  by  F[]G. 

To  specify  programs  and  to  reason  about  their  correctness,  we  use  the  fol¬ 
lowing  properties: 


init  p  =  initially  =>  p 
transient  p  =  (3c  :  c  €  D  :  p  =>  wp.c.^p) 
p  next  q  =  (Vc  :  c  €  C  :  p  =>  wp.c.q ) 

stable  p  =  p  next  p 
invariant  p  =  (init  p)  A  (stable  p) 

We  also  use  the  liveness  property  leads-to ,  denoted  by  and  defined  by  the 
following  rules: 

Transient  :  [  transient  q  =>•  true  h*  -i q  ] 

Implication  :  \p  =>  q]  =>  \p  h->  q] 

Disjunction  :  For  any  set  of  predicates  S: 

[  (Vp  :  p  S  S  :  p  (-»  q)  =>  (3p  :  p  £  S  :  p)  q] 

Transitivity  :  [p  q  /\q  r  =>  pi-tr] 

PSP  :  [p  q  As  next  t  =>  (p  A  s)  (q  A  s)  V  (->s  A  t )  ] 

Note  that  we  use  properties  with  their  inductive  definition  and  not  the  definition 
based  on  strongest  invariant  [12].  In  order  to  avoid  some  mix-up,  we  do  not  use 
the  substitution  axiom  [4],  although  we  could  when  dealing  with  global  system 
properties. 
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Another  element  of  the  theory  is  the  guarantees  operator,  from  pairs  of 
properties  to  properties.  Given  program  properties  X  and  Y,  the  property 
X  guarantees  Y  is  defined  by: 

X  guarantees  Y  ■  F  =  <VG  :  F  *  G  :  {X  ■  F^G)  =>  (Y  •  F|G)) 

In  this  paper,  we  deal  more  specifically  with  universal  properties  and  the 
guarantees  operator  is  not  used. 

For  existentiality  and  universality,  we  use  the  definition  in  [3],  which  is 
slightly  different  from  the  original  definition  in  [6].  For  any  program  property 
X: 


X  is  existential  =  <VF,  G  :  F  *  G  :  X  ■  F  V  X  •  G  =>  X  •  F[G) 

X  is  universal  =  <VF,  G  :  F  *  G  :  X  ■  F  A  X  •  G  =>  X  •  F|G) 

Properties  of  type  init,  transient  and  guarantees  are  existential  and  prop¬ 
erties  of  type  next,  stable  and  invariant  are  universal.  The  properties  leads-to 
are,  in  general,  neither  existential  nor  universal.  However,  leads-to  can  appear 
on  the  right-hand  side  of  a  guarantees  to  obtain  existential  liveness  properties 
other  than  transient  [6,  3]. 

3  The  Toy  Example 

3.1  Informal  Description 

We  consider  a  set  of  components  sharing  a  global  counter.  Each  component 
also  uses  a  local  counter.  We  are  interested  in  the  relationship  between  the 
local  counters  and  the  global  counter. 

Components  increase  a  global  counter  C  by  one  each  time  they  perform  a 
certain  action  a.  Therefore,  the  value  of  counter  C  always  equals  the  total 
number  of  actions  a  that  have  been  performed. 

In  the  remainder  of  the  section,  we  show  what  difficulties  arise  when  applying 
a  compositional  approach  to  such  a  problem,  and  how  to  solve  them.  We  specify 
the  behavior  previously  described  at  the  component  level,  and  the  correctness 
of  the  global  system  is  derived  in  a  compositional  way. 

3.2  Component  Specification 

Each  component  i  has  a  counter  Cj  of  actions  a  performed.  Therefore,  it  must 
increase  the  global  counter  C  each  time  it  increases  its  counter  Cj.  The  naive 
specification,  corresponding  to  the  case  where  the  system  is  composed  of  one 
component  i,  is: 

•  init  C  =  Ci  ■  Componenti 

•  stable  C  =  Ci  ■  Componenti 

If  all  components  share  this  specification,  we  have  two  problems: 
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•  The  initial  condition  of  the  global  system  is  (Vi  ::  C  =  c*),  from  which  we 
cannot  deduce  the  desired  property  that  C  equals  the  sum  of  the  counters 

•  If  Cj  is  local  to  component  i  and  component  j  has  to  modify  the  shared 
variable  C,  the  property  stable  C  =  Ci  is  not  satisfied  by  component  j. 

To  obtain  a  compositional  proof,  we  have  to  do  a  little  more  work.  Initially, 
C  must  equal  the  sum  of  all  the  c,,  but  expressing  this  sum  is  not  local  to  the 
component.  The  only  way  to  know  the  sum,  at  the  component  level,  is  that  all 
Cj  are  zero  (so  that  the  sum  does  not  depend  on  the  number  of  components1). 
So,  the  component  can  have  the  following  local  init  predicate: 

init  Ci  =  0  A  C  =  0  •  Componenti 

If  all  other  components  have  the  same  condition,  the  initial  state  will  satisfy  the 
condition  that  C  equals  the  sum  of  the  Cj. 

Now,  we  need  the  property  that  component  i  will  always  increase  C  and  c* 
by  the  same  value.  Formally: 

Vfc,  N  ::  a  =  k/\C  =  N  next  {3d  :  0  :  c*  =  k  +  d/\C  =  TV  +  d)  ■  Componenti 

This  is  equivalent  to: 

Vfc.  N  ::  C  =  Ci  +  N  —  fc  next  C  =  c*  +  N  —  k  ■  Componenti 
and  since  k  and  N  are  universally  quantified,  this  is  equivalent  to: 

Vfc  ::  stable  C  =  Ci  +  fc  •  Componenti 

The  last  thing  we  must  specify  to  obtain  a  compositional  specification  is 
what  variables  are  local  and  what  variables  are  shared.  This  is  achieved  through 
a  local  declaration  that  allows  to  (syntactically)  check  what  compositions  are 
valid: 

local  a  ■  Componenti 

Only  variables  not  declared  local  can  be  written  by  other  components  (here,  the 
only  non  local  variable  is  C).  From  this  local  declarations,  we  deduce  logical 
properties  in  a  generic  way: 

For  all  variables  v,  other  than  Ci  and  C,  Vfc  ::  stable  v  =  k  ■  Component j 
Finally,  at  a  logical  level,  the  specification  of  Componenti  becomes: 

init  (c*  =  0  A  C  =  0)  (1) 

Vfc  ::  stable  C  =  Ci  +  fc  (2) 

For  all  variables  v,  other  than  c,  and  C,  Vfc  ::  stable  v  =  k  (3) 

The  set  of  universal  properties  are  still  not  shared  by  other  components,  but 
we  show,  in  the  next  section,  how  a  shared  universal  property  can  be  deduced 
from  them. 

1We  could  have  init  C  =  Cj0  for  the  component  io  and  init  c*  =  0  for  the  others,  but 
this  would  introduce  a  dissymmetry. 
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3.3  Correctness  Proof 

First,  from  init  and  local  properties,  we  observe  that: 


(Vi,  j  :  i  ^  j  :  Componenti  *  Component  ■) 

Therefore,  We  can  consider  a  system  composed  of  N  components,  each  com¬ 
ponent  satisfying  the  previous  specification: 

System  =  ([]*  :  0  <  i  <  N  :  Component f) 

The  goal  here  is  to  prove  global  system  correctness  from  the  component  speci¬ 
fications.  This  desired  property  is: 


N- 1 

invariant  C  =  c*  •  System 

i—0 


Proof: 

{Component  specifications,  rewriting  (2)  and  (3)} 

For  all  i,  init  (c,  =  0  A  C  =  0)  •  Componenti 
A  For  all  i,  Vfci ,  k%,  ■  ■  ■ ,  kn  ::  stable  C  =  c,  +  kj  ■  Component i 
A  For  all  i,Vfci,  fo,  ■  ■  ■ ,  ::  stable  (Vj  :  j  ^  i  :  Cj  =  kj)  ■  Componenti 

=>  {Conjunction  of  stable  properties,  removing  unused  dummies) 

For  all  i,  init  (c,  =  0  A  C  =  0)  •  Componenti 
A  For  all  i,  stable  C  =  JT  Cj  •  Componenti 
=>  {init  properties  are  existential,  stable  properties  are  universal) 
init  {Vi  ::  (c*  =  0  A  C  =  0))  •  System 
A  stable  C  =  J2j  cj  '  System 
=>  {Predicate  calculus) 

init  C  =  J2j  cj  ’  System 
A  stable  C  =  J2j  cj  '  System 
=>  {Definition  of  invariant} 

invariant  C  =  J2j  cj  '  System 

□ 

3.4  Lessons  from  the  Toy  Example 

The  proposal  of  local  properties  (1)  and  (2)  of  Component t  was  obtained  from  an 
analysis  of  the  kinds  of  systems  in  which  we  expected  to  embed  the  component. 
In  this  sense,  we  took  a  top-down  approach  to  get  a  local  component  specification 
from  an  anticipated  system  specification.  However,  we  can  now  use  our  local 
component  specification  in  a  variety  of  systems  including  those  that  we  have 
not  anticipated. 


6 


4  The  Priority  Mechanism 

4.1  Description 

We  suppose  a  set  of  perpetually  conflicting  components:  Each  component  always 
wants  to  perform  an  action  that  requires  it  to  have  higher  priority  than  all 
its  neighbors.  These  conflicts  are  solved  by  a  priority  mechanism.  Such  a 
mechanism  should: 

•  never  give  priority  at  the  same  time  to  two  conflicting  components  (8); 

•  give  priority  to  each  component  in  turn  (9). 

We  uses  a  principle  presented  in  [4].  We  give  an  orientation  to  the  graph  of 
conflicts  so  that  it  always  remains  acyclic,  and  we  use  this  graph  as  a  priority 
graph. 

Then,  a  component  should: 

•  wait  until  it  has  priority  over  its  neighbors  (4); 

•  yield  priority  to  its  neighbors  in  finite  time  after  receiving  priority  (5); 

•  not  introduce  cycles  in  the  graph  (6). 

A  way  not  to  introduce  cycles  is  that  an  active  node  (with  a  higher  priority 
than  its  neighbors  in  the  graph),  when  changing  priorities,  always  gets  a  lower 
priority  than  all  its  neighbors. 

4.2  Component  Specification 

We  call  V  the  (nonoriented)  finite  graph  of  neighborhood.  Unless  explicitly 
specified,  a  graph  property  prop  is  to  be  understood  as  V.prop.  The  graph  V  is 
described  by  variables  N[i\: 

IV[i]  =  set  of  the  neighbors  of  Component i 

We  require  that  (Vi  ::  i  ^  N[i])  (no  node  is  conflicting  with  itself).  We  as¬ 
sume  (Vi,  j  ::  i  £  N[j]  =  j  £  N[i])  is  invariant  in  the  system  (implementation  of 
variables  N  [i] ) . 

The  graph  orientation  is  defined  by  the  arrow  The  notation  (i  — >  j) 
means  that  component  i  has  priority  over  component  j.  This  is  a  boolean  value. 
It  can  be  modified  both  by  i  and  j  and  by  no  other  node.  Any  change  must 
respect  the  (implementation)  invariant:  (Vi,  j  :  j  £  JV[i]  :  (i  -*  j)  =  ->{j  — >  i)). 

The  function  Priority. i  is  used  to  represent  the  priority  of  a  node  i  over  all 
its  neighbors: 

Priority. i  =  (Vj  :  j  £  JV[i]  :  (i  -*  j )) 
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The  three  properties  of  component  i  become: 

V6.  j  ::  j  €  iV[i]  A  (i  — >  j)  =  b  A  ^Priority, i  next  (i  — ►  j)  =  b  ■  Component j(4) 
transient  Priority. i  ■  Componenti  (5) 

Priority. i  next  Priority. i  V  (Vj  :  j  6  A7[i]  :  (j  — m))  •  Componenti  (6) 

As  previously,  we  add  a  locality  constraint:  A  component  cannot  change 
edges  other  than  its  incoming  and  outcoming  edges: 

Vb,  j,  j1  v.j^iAj'^iA  ( j  ->  j1)  =  b  next  (j  ->•  j1)  =  b  ■  Componenti  (7) 

4.3  System  Specification 

Here,  we  express  formally  the  system  specification  previously  informally  stated: 

•  safety: 

invariant  {Vi  ::  Priority. i  =>  (Vj  :  j  £  fV[i]  :  ^Priority .j))  ■  System  (8) 

•  liveness: 

Vi ::  true  e->-  Priority. i  ■  System  (9) 

The  proof  of  safety  is  trivial.  To  prove  the  liveness  part,  we  use  the  fact 
that  the  graph  always  remains  acyclic,  and  therefore  that  there  is  always  a  node 
which  has  the  priority.  To  achieve  that,  we  have  to  build  a  global  universal 
property,  satisfied  by  all  components,  from  which  we  can  deduce  the  graph 
acyclicity.  It  corresponds  to  the  step  presented  in  the  toy  example  to  obtain 
the  property  invariant  C  =  JA  Cj.  However,  here,  the  property  is  more  tricky 
(see  property  (13)). 

4.4  Notations 

In  order  to  express  this  acyclicity,  we  define  the  functions2  R.i  and  A.i : 

R.i  =  {j  :  j  €  N[i]  :  ( i  ->  j)} 

A.i  =  { j  :  j  €  IV[?;]  :  ( j  i)} 

and  a  kind  of  (nonreflexive)  transitive  closure  R*.i  and  A*.i: 

Rl.i  =  R.i  Vn,  Rn+1.i  =  Rn.i  U  (J  R.j  R*.i={jRn.i 

j£Rn.i  n>  0 

R*.i  is  the  set  of  nodes  reachable  from  node  i  following  the  graph’s  edges.  A*.i 
is  defined  in  the  same  way  and  is  the  set  of  nodes  from  which  the  node  i  is 
reachable. 

2Defining  R.i  and  A.i  as  functions  instead  of  relations  allows  the  use  of  set  operators  to 
simplify  the  writing  of  some  formulas. 
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We  use  the  following  property  for  all  i  and  j: 

[i  e  R*.j  =  j  €  A*.i]  (10) 

Then  the  graph  acyclicity  is  defined  by: 

Acyclicity  =  (Vi  ::  i  $  i?*.i) 

=  (Vi  ::  i  i  A*  A) 

We  also  use  the  equivalent  definition  of  Priority.i: 

Priority. i  =  A*,  i  =  0  (11) 


4.5  Construction  of  a  Universal  Property 

Definition  1  Let  G  and  G'  be  two  graphs  differing  only  by  edge  orientation. 
We  say  that  G'  is  derived  from  G  through  node  io  if  and  only  if  all  the  edges  of 
i o  are  outcoming  in  G  and  incoming  in  G' ,  all  other  edges  being  equal  in  G  and 
G'. 


G^G'  = 

(Vfc,  k'  :  k,k'  ytzi0  :  G.(k  ->  k1)  =  G' .(k  ->  k1))  A  G.A*.i0  =  0  A  G'.R*.i0  =  0 

Lemma  1  If  a  graph  G'  is  derived  from  a  graph  G  through  node  io,  then  the 
reachability  of  nodes  in  G'  cannot  be  greater  than  the  union  of  what  they  are  in 
G  and  the  singleton  {io}- 

[G&G1  =>  (Vi  ::  G1  .R* .i  C  G.R*  A  U  {i0})] 

Proof:  From  graph  theory.  □ 

Property  12  The  only  changes  a  component  i  can  make  in  the  priority  graph 
are  governed  by  the  relation 

VG  ::  V  =  G  next  P  =  GVG'^P  -  Componenti  (12) 

Proof:  Trivial  from  the  specifications  (4),  (6)  and  (7)  of  component  i.  □ 

Property  13  (Universal  system  property) 

VG  ::  V  =  G  next  V  =  G  V  (3i0  ::  G  &  V)  ■  System  (13) 

Proof:  From  (12),  the  property  is  satisfied  by  every  component.  Since  next  is 
universal,  this  is  a  system  property.  □ 
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4.6  Proof  of  the  Liveness  Property  (9) 

Property  14  A  component  cannot  enter  any  reachability  set  before  it  has  pri¬ 
ority. 

Vi,  j  ::  A* A  ^  0  A  i  f  R* .j  next  i  f  R* .j  ■  System  (14) 

Proof:  From  lemma  1  and  (13): 

VG,  r,  i,  j  :: 

V  =  G/\R*.j=r/\A*.i^®/\i^r 
next 

P=GV  (3i0  ::  G  Q>V  A  R*.j  C  r  U  {io}  A  i  $  r)  ■  System 

If  V  =  G,  then  R*.j  =  r  and  then  i  R*.j.  If  not,  from  G  Q  V,  we  know  that 
G.A*  Aq  =  0.  Therefore,  io  i,  and  since  i  $.r,  we  deduce  that  i  $  R* A.  Using 
disjunction  over  G  and  r,  we  obtain  (14).  □ 

Property  15  A  component  with  priority  will  keep  its  reachability  set  or  its 
above  set  empty. 

Vi ::  A*  A  =  0  next  A*  A  =  0  V  R*  A  =  0  •  System  (15) 

Proof:  If  a  component  has  priority,  its  neighbors  cannot  have  priority  and, 
thanks  to  (4)  and  (7),  cannot  change  any  edge.  Therefore,  its  neighbors  cannot 
set  its  own  priority  to  false.  That  means  that  (6)  is  satisfied  by  all  components. 
Since  it  is  universal,  it  is  a  system  property: 

Vi  ::  Priority  A  next  Priority  A  V  (Vj  :  j  G  Ar[i]  ::  ( j  — >  i))  •  System 

Then,  just  rewriting  using  R*  A  and  A*  A,  we  obtain  exactly  (15).  □ 

Property  16  If  it  is  acyclic  initially,  the  priority  graph  remains  acyclic. 

Acyclicity  next  Acyclicity  ■  System  (16) 

Proof:  From  (14),  choosing  i  =  j,  we  have: 

Vi  ::  A*  A  ^  0  A  i  ^  R*  A  next  i  ^  R*  A  ■  System 

From  (15),  using  i  G  R* A  =  i  G  A*  A: 

Vi  ::  A*  A  =  0  next  i  $  R*  A  ■  System 

From  the  disjunction  of  the  two  above,  strengthening  the  left-hand  side  of  the 
next: 

Vi  ::  i  R*.i  next  i  ^  R* A  ■  System 
which,  from  the  definition  of  Acyclicity ,  is  exactly  (16).  □ 
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Lemma  2  There  is  at  least  one  maximal  node  in  any  nonempty  above  set  of  a 
finite  acyclic  graph. 

[. Acyclicity  =>•  (Vi  :  A*  A  ^  0  :  (3j  :  j  G  A*  A  :  A*  .j  =  0))] 

Proof:  From  graph  theory.  □ 

Property  17  Any  nonpriority  component  has  always  a  priority  component 
above  it. 

Vi  ::  invariant  Acyclicity  A  {A* A  ^  0  =>•  (3 j  :  j  G  A* .i  :  A* .j  =  0))  •  System 

(17) 

Proof:  From  lemma  2  and  (16).  □ 

Property  18  Any  component  with  priority  eventually  escapes  every  above  set. 

Vi.  j  ::  A* A  =  0  t->  i  $  A* .j  ■  System  (18) 

Proof:  From  the  existential  characteristics  of  (5),  we  have: 

Vi  ::  transient  Priority  A  ■  System 

that  rewrites: 

Vi  ::  A* A  =  0  A*  A  ^  0  ■  System 
From  (15)  and  the  above,  using  PSP: 

Vi  ::  A*  A  =  04  R*  .i  =  0  •  System 

Since  i  G  A* .j  =  j  G  R*.i: 

Vi  ::  ^4*.i  =  0  i-4  (Vj  ::  i  ^  A* .j)  ■  System 

which  is  stronger  than  the  required  property  (18).  □ 

Finally,  we  prove  the  liveness  correctness  (9),  which  is  equivalent  to  the 
following  property: 

Property  19 

Vi  ::  true  h-4  A*  A  =  0  •  System  (19) 

Property  (14)  is  equivalent  to: 

Vi,  j  ::  A*  A  ^  0  A  j  A*  A  next  j  ^  ^4*.i  •  System 
which  in  turn  is  equivalent  to: 

Va,  i ::  A*  A  =  a  ^  0  next  A*  A  C  a  ■  System 
In  the  same  way,  from  (18)  we  have: 

Vo,  i,  j  ::  A*  A  =  a  A  j  G  ^4*.i  A  A* .j  =  Q  j  ^  a  ■  System 
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Applying  PSP  to  the  two  above,  we  obtain: 

Va,  i,j  ::  A*  A  =  a  Aj  €  A*  A  A  A*.j  =  0  A*.i  £  a  ■  System 

Using  leads-to  disjunction  over  j ,  it  becomes: 

Va,  i  ::  A*i  =  a  A  (3j  :  j  €  A*i  :  A*.j  =  0)  A*i  £  a  •  System 

From  the  invariant  (17),  A* A  ^  0  =>  (3j  :  j  €  A*i  :  A*.j  =  0),  and  therefore, 
the  previous  formula  implies: 

Va,  i ::  =  a  ^  0  i->  A* A  £  a  ■  System 

Through  induction  on  the  cardinality  of  A*.i,  this  gives  the  liveness  correct¬ 
ness  (9). 

5  Conclusions 

This  paper  explores  a  methodology  for  compositional  development  of  systems. 
The  methodology  attempts  to  work  with  two  types  of  system  properties:  uni¬ 
versal  and  existential.  A  goal  of  the  methodology  is  to  specify  components 
using  only  local  properties.  In  some  cases,  system  properties  can  be  obtained 
in  a  straightforward  fashion  from  local  component  properties.  In  other  cases, 
creativity  is  required  to  derive  system  properties  from  local  properties. 

This  case  study  exposes  the  use  of  three  kinds  of  compositional  properties: 

•  an  existential  property  (5); 

•  a  universal  property,  shared  by  all  components  (6) ; 

•  a  universal  property,  not  shared  by  other  components  (4). 

The  first  two  types  of  property  are  easy  to  use:  they  simply  hold  in  the  global 
system  when  components  are  gathered.  The  third  one,  however,  requires  cre¬ 
ativity  and  additional  work  to  become  useful  in  the  composition  step.  The 
case  studies  help  us  in  exploring  compositional  steps  that  appear  to  be  almost 
mechanical  in  contrast  to  steps  that  require  some  ingenuity. 

The  specification  of  the  conflict  resolution  solution  included  the  property 
that  the  graph  of  the  priority  relation  is  an  acyclic  graph.  We  could  have 
specified  the  components  in  terms  of  such  acyclic  graphs,  but  this  would  have 
resulted  in  component  specifications  being  nonlocal.  The  specification  of  one 
component  would  include  properties  about  the  priority  relationship  between 
completely  different  components.  If  we  specify  components  using  only  local 
properties,  then  we  have  to  bridge  the  gap  between  local  properties  and  the 
global  system  property  about  acyclic  graphs.  We  found  no  mechanical  way  of 
bridging  this  gap. 

The  principle  used  to  build  a  universal  shared  property  is  to  weaken  the 
component  properties  so  that  all  components  can  share  the  weakened  property. 
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This  transformation  requires  some  knowledge  on  how  shared  variables  are  mod¬ 
ified  by  other  components.  This  knowledge  is  provided  by  other  components 
(universal)  specification. 

Note  that  this  step  leads  to  weaken  a  property,  and  is  not  exactly  a  refine¬ 
ment  step  in  the  strict  sense  of  the  word  [2,  11].  Such  transformations,  in¬ 
troducing  some  nondeterminism,  seem  to  appear  frequently  when  dealing  with 
distributed  programs  [9,  7]. 

Universal  properties  seem  to  be  closely  related  to  global  safety.  In  the  prior¬ 
ity  example,  the  safety  correctness  is  trivial,  but  we  need  a  strong  safety  property 
to  prove  the  liveness  part.  In  [3],  a  resource  allocator  example  is  derived.  In 
that  example,  all  the  safety  points  are  local  to  components  and,  actually,  the 
example  only  makes  use  of  existential  properties. 

Another  point  worth  being  noticed  is  that,  in  both  the  toy  example  and 
the  priority  mechanism  example,  we  only  make  use  of  statement  properties 
( transient  or  inductive  safety  properties).  Properties  like  “always  true”  are 
avoided.  The  theory  provides  a  guarantees  operator  to  deal  with  non  transient 
existential  properties.  However,  for  universal  properties,  nothing  more  than 
inductiveness  is  used. 

We  are  currently  investigating  such  questions,  both  from  the  theoretical 
point  of  view  and  by  applying  the  theory  of  composition  to  a  collection  of 
examples.  In  particular,  we  are  working  on  developing  a  theory  based  on  the 
traditional  rely-guarantee  approach  [8,  13]  and  relating  it  to  other  theories  of 
composition  [10,  1]. 

The  vision  that  drives  us  is  that  of  modularity  at  the  level  used  by  manu¬ 
facturers  of  personal  computers,  cars  and  airplanes.  Such  systems  are  complex 
with  large  numbers  of  parts.  We  should  be  able  to  compose  certain  kinds  of 
software  modules  in  the  same  way. 

Just  as  there  have  been  many  generations  of  airplanes  we  now  are  moving 
towards  many  generations  of  user  interfaces,  and  the  compositional  technologies 
that  the  community  has  learned  in  building  airplanes  over  many  generations  are 
now  being  used  to  build  user  interfaces  and  other  software  systems.  The  trend 
towards  plug-and-play,  object  systems,  and  component  systems  such  as  Java 
Beans  and  Microsoft’s  DCOM  are  examples  of  steps  in  this  direction. 

Formal  theories  that  support  compositional  development  of  concurrent  sys¬ 
tems  have  been  proposed.  This  work  is  an  exploration  of  a  theory  based  on 
specifications  using  only  local  properties  and  two  types  of  properties:  universal 
and  existential.  We  believe  that  this  theory  is  worthy  of  further  investigation  be¬ 
cause  of  the  extreme  simplicity  of  its  foundation  and  the  successful  case  studies 
of  its  use. 
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